home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0146.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  2.4 KB  |  60 lines
  1. Terry Gray <gray@cac.washington.edu> writes:
  2. > I didn't argue *for* storing the info on the client; I only argued
  3. > *against* assuming it would be stored and used on the server.
  4.  
  5. If the advice to clients is reasonably interpreted as "ignore the
  6. /SEEN flag for bboards and handle the per-user state yourself", then I
  7. fear clients will store this information in the simplest and most
  8. logical place (the local disk) and be done with it.  Given your
  9. reference to "the" public news and/or archive server, I think this is
  10. a reasonable interpretation of what you're saying.
  11.  
  12. > I tend to believe the world is simpler if we assume the public
  13. > news and/or archive server has no notion of users, and per-user state info
  14. > is manipulated by the client.
  15.  
  16. Any distributed mechanism available to the client for handling this
  17. information is at least equally available to the server.  As there are
  18. usually fewer varieties of servers than clients, and as servers
  19. usually don't run on low-resource machines, I believe it is much
  20. simpler to get all servers to handle this correctly than to get all
  21. clients to do so.
  22.  
  23. Keith Moore <moore@cs.utk.edu> writes:
  24. > And putting the state information on the server is contrary to the
  25. > goal of fault-tolerance and scalability.
  26.  
  27. Not at all.  The server can use a replicated, distributed database to
  28. store the information.
  29.  
  30. > I can see a mail reader talking to two IMAP servers at once -- a mailing
  31. > list archive server to peruse the old messages, and the user's "home"
  32. > mailbox server -- to keep track of seen state.
  33.  
  34. You're getting close to our vision--multiple IMAP servers in a domain,
  35. mailboxes and bboards distributed and/or replicated across them to
  36. distribute load, and a service (IMSP) to allow a client to find out
  37. where everything is and transparently present it to the users as one
  38. big, happy namespace.
  39.  
  40. > I can also envision the "home" mailbox server as sort of "local
  41. > cache" for a particular list, where the mail reader will fetch
  42. > articles from a remote server if necessary, to present a unified
  43. > view of the list traffic.
  44.  
  45. Our experience shows that intermediary servers tend not to scale well.
  46. They're certainly not necessary to present a unified view.
  47.  
  48. > (In which case, readers would not have to subscribe to a list that
  49. > they read only occasionally...)
  50.  
  51. I don't subscribe to mailing lists, period.  I read all mailing lists
  52. (including this one) as bboards.
  53.  
  54. -- 
  55. _.John G. Myers        Internet: jgm+@CMU.EDU
  56.             LoseNet:  ...!seismo!ihnp4!wiscvm.wisc.edu!give!up
  57.  
  58.  
  59.  
  60.